home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.20000824-20010305 / 000159_news@columbia.edu _Fri Dec 29 13:12:36 2000.msg < prev    next >
Internet Message Format  |  2001-03-05  |  3KB

  1. Return-Path: <news@columbia.edu>
  2. Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
  3.     by monire.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA18333
  4.     for <kermit.misc@cpunix.cc.columbia.edu>; Fri, 29 Dec 2000 13:12:35 -0500 (EST)
  5. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  6.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id NAA24179
  7.     for <kermit.misc@watsun.cc.columbia.edu>; Fri, 29 Dec 2000 13:12:35 -0500 (EST)
  8. Received: (from news@localhost)
  9.     by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id NAA08497
  10.     for kermit.misc@watsun.cc.columbia.edu; Fri, 29 Dec 2000 13:10:44 -0500 (EST)
  11. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  12. From: fdc@columbia.edu (Frank da Cruz)
  13. Subject: Re: Converting struct tm to time_t
  14. Date: 29 Dec 2000 18:10:43 GMT
  15. Organization: Columbia University
  16. Message-ID: <92ik33$89f$1@newsmaster.cc.columbia.edu>
  17. To: kermit.misc@columbia.edu
  18.  
  19. In article <ylito3uonk.fsf@windlord.stanford.edu>,
  20. Russ Allbery  <rra@stanford.edu> wrote:
  21. : INN currently uses [the following], which seems to work fairly well.  I'm
  22. : the author of this code; you can consider it to be in the public domain.
  23. : Note that this code requires that time_t be an arithmetic type, which may
  24. : not work properly on some non-UNIX platforms (it could presumably be
  25. : replaced by a long or something).
  26. Thanks.  Yes, I always knew I could do the day/month/year/time arithmetic
  27. myself, and already do this kind of thing in other parts of the Kermit code,
  28. but not for interfacing with system APIs, e.g. see:
  29.  
  30.   http://www.columbia.edu/kermit/case17.html
  31.  
  32. As you say, your code does presume a few things about what time_t is:
  33.  
  34.  . An integer (in the mathematical sense), unsigned.
  35.  . The number of seconds since 1 Jan 1970 0:00:00.
  36.  
  37. If that is always true, fine.  Of course the whole purpose of having, and
  38. making us use, fabrications like time_t is to hide all that from us.  Who
  39. knows what our UNIX vendors will come up with as we approach the 2038 barrier
  40. that will break these assumptions.
  41.  
  42. Anyway, I suppose it's worth a shot.  In the meantime, too bad whoever
  43. thought of mktime() didn't make it do just one thing (in the UNIX spirit),
  44. instead of two things at once, without allowing those things to be done
  45. separately.
  46.  
  47. Another solution that had occurred to me was to compare the localtime() and
  48. gmtime() results for the same clock time, figure out the GMT/UTC offset, and
  49. deduct it to the target struct tm before passing it to mktime(), but gmtime()
  50. and localtime() are not among the most portable of UNIX APIs, plus I don't
  51. know how consistent their semantics are across platforms, e.g. if you give
  52. them a seconds or minutes field greater than 60 or less than 0, etc.
  53.  
  54. Thanks again.
  55.  
  56. - Frank